home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13339 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: news.jaguNET.com!news
  2. From: droddey@jagunet.com
  3. Newsgroups: alt.computer.consultants,comp.edu,comp.lang.basic.misc,comp.lang.c++,comp.lang.misc,comp.lang.pascal.borland,comp.lang.pascal.delphi.misc,comp.misc,comp.os.msdos.programmer,comp.os.os2.programmer.misc,comp.programming
  4. Subject: Re: Can we do programming without seeing the end user?
  5. Date: 25 Mar 1996 03:13:59 GMT
  6. Organization: jaguNET Access Services
  7. Message-ID: <4j531n$4nh@skydiver.jaguNET.com>
  8. References: <BYtKnOggyTxQ071yn@oslonett.no>
  9. Reply-To: droddey@jagunet.com
  10. NNTP-Posting-Host: dlup-a19.jagunet.com
  11. X-Newsreader: IBM NewsReader/2 v1.2.5
  12.  
  13. In <BYtKnOggyTxQ071yn@oslonett.no>, bollerud@oslonett.no (Svein Olav Mytting) writes:
  14. >I know a lot of you programmers work far from the end-users. Some of you
  15. >work even far from your employer, which in turn lives far from the
  16. >customer.
  17. >
  18. >I sort of believe that sales and programming should be strictly
  19. >separate tasks. While a salesman should see his customer in person,
  20. >a programmer shouldn't do that.
  21. >
  22. >My simple question is this: To which a degree can software development
  23. >be done using electronic communication as the only contact with the
  24. >sales people and/or end users?
  25. >
  26.  
  27. It depends upon who the customer is. If the developer him/herself is an experienced
  28. user of that particular kind of software, then extensive contact with the end user
  29. might not be a big deal.
  30.  
  31. If the developer knows absolutely nothing about the problem domain (and is
  32. therefore only there for technical software expertise) then its kind of up in the
  33. air. You can make the argument that this person would be totally useless as an
  34. interviewer of end users because he/she would not speak the language and would
  35. likely make many errors even attempting to gather user requirement him/herself.
  36. Perhaps in that situation, a problem domain expert should work with the developer
  37. to do that kind of work.
  38.  
  39. If the developer is somewhere in between those two extremes, its kind of a toss
  40. up as to what would be best.
  41.  
  42. A personal 'for instance' is that I write development tools for other developers. So
  43. I know very well what problem domain is and what the requirements are because
  44. I have the same needs from the software as my 'customer' would. At work though,
  45. I am in a clinical information software domain. I know pretty much nada about that
  46. world and what their needs are. So I am very removed from requirement
  47. determination because there are lots of non-development (but not sales, they are
  48. domain experts) folks there who can do that better than me.
  49.  
  50.  
  51. Dean Roddey
  52. CIDCorp, The CIDLib Class Libraries
  53. droddey@jagunet.com
  54. http://www.jagunet.com/~droddey/
  55.  
  56.  
  57.